fix(tickets): page_size ignored on first page, dateoccurred_start/end silently ignored - #63
Merged
Merged
Conversation
… silently ignored
TicketsResource.list() (and every other resource's .list(), via the shared
addPageinate() helper) sent page_size alone when the caller didn't also pass
page_no. HaloPSA only honors page_size when page_no is present on the same
request -- with page_size alone it silently falls back to its own default
page size (50) for that implicit first page, no error. A caller paging with
limit=100 got 50 records back on page 1, then page_no=2/limit=100 correctly
started at offset 100 -- so ids 50-99 (what page 1's requested size should
have covered) were never returned by any call in the sequence. This also
explains why record_count only reported the true total on explicit paged
calls: it only reflects the full total once pagination is genuinely active
on every request. addPageinate() now defaults page_no to 1 whenever
page_size is set without it, matching what the SDK's own PaginatedIterable
(used by .listAll()) already did correctly on every page.
Separately, TicketsResource sent dateoccurred_start/dateoccurred_end to the
API verbatim as query params -- neither exists in HaloPSA's actual API
(confirmed against the live /api/swagger/v2/swagger.json spec), so they were
accepted and silently ignored with no filtering applied and no error. The
real mechanism is a generic datesearch=<field> parameter plus startdate/
enddate ('dateoccured', missing the second 'r', is HaloPSA's own misspelling
of the date-opened field, not ours). list()/listAll() now translate the pair
into datesearch=dateoccured&startdate=...&enddate=... before the request.
Reported-by: community (client_id=467 pagination trace showing the gap;
Aug 2025-May 2026 date window silently returning the unfiltered set)
github-actions Bot
pushed a commit
that referenced
this pull request
Aug 21, 2026
## [1.0.10](v1.0.9...v1.0.10) (2026-08-21) ### Bug Fixes * **tickets:** page_size ignored on first page, dateoccurred_start/end silently ignored ([#63](#63)) ([c662f30](c662f30))
3 tasks
asachs01
added a commit
to wyre-technology/halopsa-mcp
that referenced
this pull request
Aug 21, 2026
…ose search (#83) Bumps @wyre-technology/node-halopsa to 1.0.10, which fixes two bugs reported against halopsa_tickets_list: - limit was silently ignored on the first page (page_size alone, without an explicit page_no, was accepted and ignored by HaloPSA -- it fell back to its own default page size of 50 for that implicit first page, leaving a gap between it and an explicit page_no=2 request). This also explains the reported record_count inconsistency, which only reflected the true total once pagination was genuinely active on every request. - dateoccurred_start/dateoccurred_end were accepted and silently ignored -- neither is a real HaloPSA query parameter (confirmed against HaloPSA's own swagger spec); the SDK now translates them into the real datesearch=dateoccured + startdate/enddate mechanism. See wyre-technology/node-halopsa#63 for the SDK-level fix and verification. Also exposes the search parameter (already supported by the SDK and HaloPSA's API, just not surfaced on this tool) on halopsa_tickets_list, replacing what previously required a multi-page sweep with a single call. Reported-by: community (client_id=467 pagination trace; Aug 2025-May 2026 date window silently returning the unfiltered set)
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Two ticket-listing bugs reported by a community user running halopsa-mcp v1.7.9:
page_sizeignored on the first page. HaloPSA only honorspage_sizewhenpage_nois also present on the same request —page_sizealone is accepted but silently ignored, falling back to HaloPSA's own default (50) for that implicit first page.addPageinate()(shared by every resource) now defaultspage_noto1wheneverpage_sizeis set without it, matching whatPaginatedIterable(.listAll()) already did correctly on every page. This also explains the reportedrecord_countinconsistency — it only reports the true total once pagination is genuinely active on every request.dateoccurred_start/dateoccurred_endsilently ignored. Neither is a real HaloPSA query parameter — confirmed directly against the live/api/swagger/v2/swagger.jsonspec. The actual mechanism isdatesearch=dateoccured(HaloPSA's own misspelling) +startdate/enddate.TicketsResource.list()/.listAll()now translate the pair before the request goes out.Verified
npm run typecheck/npm run lint/npm run build: cleannpm test: 264/264 passingNote for a follow-up (not fixed here)
While tracing this, I found
AppointmentListParams(src/types/appointments.ts) has the identically-shapedstartdate_start/startdate_endsynthetic filter pair, andAppointmentsResource.buildListParamsstill passes them through untranslated — the same latent bug, just not the one reported. Leaving that out of scope for this PR since it wasn't reported and I don't want to bundle an unverified fix; flagging here in case it's worth its own issue.Test plan
addPageinate()'s newpage_nodefault (both the "defaults to 1" and "doesn't override an explicit page_no" cases)page_no/page_size/pageinatequery params on a single-page.list()calldateoccurred_start/dateoccurred_endtranslate todatesearch/startdate/enddateand don't leak through verbatimNeed help on this PR? Tag
@codesmith-botwith what you need. Autofix is enabled.